iT邦幫忙

2024 iThome 鐵人賽

DAY 5
1
AI/ ML & Data

資料決策時代:從零開始打造公司數據引擎與決策文化系列 第 5

MySQL 關聯式資料庫(一):資料表的設計, ERD、轉換資料表與正規化

  • 分享至 

  • xImage
  •  

前言-為什麼要更了解 MySQL


在進入 OLAP 的設計探討之前,我想先再多聊聊 MySQL 關聯式資料庫的核心概念,你必須先掌握 OLTP 遇到了什麼問題,才能客觀評估是不是真的需要導入 OLAP 、要導入到什麼程度?

另外在打造線上資料服務時,也經常會把後端需要即時存取的資料回存到 MySQL,對於資料表的設計可能就要涉略一些了。

接下來,我們分成資料表設計查詢與效能優化兩個主題來聊聊。

以下我們用一個簡化的用戶情境來輔助說明:

我們要打造一個學習管理系統,在國小的學校中,老師會有導師、科任老師,導師會帶一個班級,一
班大約有30-35個學生,科任老師的話就會同時教好幾個班。
每天看老師上課進度而有回家作業,老師希望能把這些學生學習的紀錄都留存下來,讓他好
追蹤學生的學習狀況,老師通常每天會去批改作業,看看學生是不是都完成了,還有答對多
少,每個月也會檢視一下學生在每一個科目的學習表現。

資料表需求訪談與設計


ERD (Entity Relationship Model) 及如何轉換成資料表

實體關係模式,用來將真實世界的需求進行功能性分析以後,透過圖像化的方式,把需求轉換成資料種類和其關係,便於我們和需求方溝通,也方便後續轉換成資料表的設計,其中元件可以分成實體(Entity)關係(Relationship)

實體

一個 實體 代表一個事物,實體會包含 屬性 ,像是老師的姓名、生日等等,或是學習記錄有對應的科目、學習的時間,需要額外注意的是屬性可能會有多值(但這裡求簡單介紹,就不深入)。

關係

關係可以分成一對一、一對多以及多對多,這裡的關係類型,就會決定後續如何轉換成資料表。

圖像表示法

  1. 實體:用長方形框框代表
  2. 屬性:用橢圓形代表
  3. Key 值:用來識別資料的唯一值,會加上底線
  4. 關係:用菱形代表,並在兩邊線加上 1:1, 1:N, N:M 來代表關係

https://ithelp.ithome.com.tw/upload/images/20240919/20114297UDchXfn2JM.png

ERD 關係轉換成資料表設計的案例實作

ERD 的實體與屬性的表示在上圖可以看到,接著我們花一點點篇幅來介紹不同數量關係,是怎麼被轉換成資料表設計的:

老師可能是導師、科任老師,可能教一個班級,也可能可以教多個班級,我們剛好拿這個情境來分別舉例 一對一、一對多以及多對多

  1. 一對一:假設我們的系統中,老師只有導師,只能教一個班級,一個班級也只有一個導師。一對一的實體關係建立很簡單,『任選一個你覺得適合,把 key 放到另一張表上作為 Foreign Key 外部鍵』,就完成對應。
    ** 註記: 為了跟一對多做出區別介紹,這邊選擇將 class_id 放到 teacher上。**

https://ithelp.ithome.com.tw/upload/images/20240919/20114297ClB65yJr1R.png

  1. 一對多:老師是導師,但考慮老師每年都會帶班,所以從系統角度,一個導師會帶多個班,但每個班級只有一個導師。
    一對多的實體關係,『將一個數量實體 key 放到多個數量實體上作為 Foreign Key 外部鍵』,就完成對應。(結果看起來可能會跟一對一的一樣)

https://ithelp.ithome.com.tw/upload/images/20240919/20114297XDn4sykiHf.png

  1. 多對多:我們希望簡化系統設計,把導師、科任老師都先歸類在老師,一個老師可以教多個班級,每個班級也會有多個老師,在多對多關係的狀態下,會獨立出一張資料表來記錄關聯,而兩個實體的主鍵會同時被放到這張表上,成為超級鍵(複合型的主鍵)

https://ithelp.ithome.com.tw/upload/images/20240919/2011429736EOodUK9u.png

資料表設計的正規化


接著我們來聊聊正規化(Normalization),正規化的目的是為了讓關聯式資料庫的效率更好,也避免幾個問題發生:

  1. 實體意義不明
  2. 資料重複儲存
  3. 很多空值

正規化分成五個等級,1NF, 2NF 一直到5NF,基本上只要滿足1~3NF 即可。

1NF: 每個屬性都是簡單而且單值

簡單來說,就是一個欄位就是一個值,不該存多個值。

https://ithelp.ithome.com.tw/upload/images/20240919/20114297YYjR9oxP8D.png

2NF:完全函數相依,不該儲存不屬於該實體的資料

這比較偏概念,你怎麼定義兩個實體概念一樣或是不一樣,例如:老師和班級就是不一樣,不該把班級的資訊,放在老師的資料表中。
看似簡單,但是實務上蠻常見的問題,可能是

  1. 分不清楚兩個實體要不要分開存,沒考慮好未來的使用情境,
  2. 有時候求快不想多一次JOIN拿資料,就直接把新增的欄位加在既有資料表上,就是長期累積的技術債。

https://ithelp.ithome.com.tw/upload/images/20240919/20114297WzX18eKhiA.png

3NF:不該存在遞移相依,也就是 X->Y, Y->Z 的關係存在

遞移關係的存在,必須透過資料表去建立出來,如果同時存在同一張表上,就會產生非常多的重複資料。

https://ithelp.ithome.com.tw/upload/images/20240919/20114297HhlTAhMt2D.png

小結


今天我們聊完了MySQL 關聯式資料庫從需求訪談,到轉換成資料表,最後到如何檢查自己的資料關係設計是沒問題的,這個過程會一直來來回回去做調整,但也確保你接下來的系統邏輯層會在一個可靠的資料層上去工作,下一篇我們來聊聊 MySQL 的SQL效能優化。
這篇算是非常簡潔的帶過了設計的概念,如果真的想實務操作,建議深入閱讀中山大學資管系黃三益教授的著作《資料庫的核心理論與實務》,也有較舊版的線上內容可以先行參考,非常推薦!
https://www.mis.nsysu.edu.tw/db-book/home.htm


上一篇
Row-based 與 Columnar Database
下一篇
MySQL 關聯式資料庫(二):Index、B+Tree 與 SQL 查詢優化
系列文
資料決策時代:從零開始打造公司數據引擎與決策文化30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言